It’s the shooter season of the year and this fall was all about Modern Warfare 3 versus Battlefield 3. And being the kind of game they are they also try to keep their audience playing by introducing some additional level of engagement. Both Call of Duty and Battlefield introduced their own online community websites and statistic platforms. Call of Duty has Elite, Battlefield has Battlelog.

这是一年中的射击季节，今年秋天全都涉及《现代战争3》和《战地3》。作为一种游戏，他们还试图通过引入更多参与度来吸引观众。 《使命召唤》和《战地风云》都引入了自己的在线社区网站和统计平台。 使命召唤拥有精英，战地拥有Battlelog。

But just because these services are sitting in the same spot it does not mean they are in any way similar. And that actually goes for more than just their monetization plans and feature sets. Elite is a traditional application as traditional as it can be. You sign up, there is Flash, there is a bit of JavaScript, there are tons of requests for each page and a playercard transmits about 3 MB of data to your client. Not very interesting to say the least.

但是，仅仅因为这些服务位于同一地点，并不意味着它们在任何方面都相似。 实际上，这不仅仅是他们的获利计划和功能集。 Elite是一种尽可能传统的传统应用程序。 您进行了注册，有了Flash，有了一些JavaScript，每个页面都有大量的请求，并且播放器卡向您的客户端传输大约3 MB的数据。 至少可以说不是很有趣。

But what are they doing? Notwithstanding some of their respective extra features both Battlelog and Elite are essentially a social network for shooter games that expose the statistics of your individual gameplay as well as the one of your friends to you. Everything you do in the game is reflected on these websites and you can further interact with the game there by commenting on gameplay and chatting up with friends.

但是他们在做什么？ 尽管Battlelog和Elite都有各自的一些额外功能，但它们本质上都是射击游戏的社交网络，可将您的个人游戏玩法以及您的好友之一的统计信息公开给您。 您在游戏中所做的一切都会反映在这些网站上，您可以通过评论游戏玩法并与朋友聊天来进一步与游戏互动。

Elite by itself is not very interesting technology wise, however Battlelog certainly is. It shows that an application that is probably used by millions of gamers can be built on modern web technology as well. And under the hood is one of the most interesting ways to built a modern web application that I think you should check out.

精英本身并不是很有趣的技术，但是Battlelog确实是。 它表明，可能由数百万游戏玩家使用的应用程序也可以基于现代Web技术构建。 在幕后，构建现代Web应用程序是最有趣的方法之一，我认为您应该检查一下。

A few months back I was claiming that WSGI is not the place for pluggable applications and that it would make sense to assemble applications on the client-side. Turns out, Battlelog is doing just that. While I do not know what all of their infrastructure looks like, their network graph and license information on the page is revealing.

几个月前，我声称WSGI不是可插拔应用程序的场所，并且在客户端组装应用程序是有意义的。 事实证明，Battlelog就是这样做的。 虽然我不知道他们的所有基础架构是什么样子，但页面上的网络图和许可证信息却在显示。

Battlelog is written by a company called ESN and their infrastructure from the released code is basically Python 2.x with gevent as well as JavaScript with jQuery and their own stuff on the client and Java for their websocket backend.

Battlelog由一家名为ESN的公司编写，其发布代码中的基础结构基本上是带有gevent的Python 2.x，以及带有jQueryJavaScript和它们在客户端和Java上用于websocket后端的东西。

If you send an HTTP request to the website it appears to work as if it was a regular website. You get a bunch of HTML rendered and nothing interesting happens. However if you click on any link you do not get HTML transmitted. Instead what is transmitted is JSON, the HTML5 history API is used to modify the URL dynamically and all the HTML is rendered on the client. Since it appears to be able to do both we can compare the sizes of the data transmitted easily.

如果您将HTTP请求发送到网站，则它似乎可以正常运行。 您得到了一堆呈现HTML，没有发生任何有趣的事情。 但是，如果单击任何链接，则不会传输HTML。 传输的是JSON，而是使用HTML5历史记录API动态修改URL，并将所有HTML呈现在客户端上。 由于两者似乎都能做到，因此我们可以轻松比较传输的数据大小。

The HTML for the index page is 18KB in size. If we trigger the request to the same URL with just the JSON it’s 4KB. Not only is it less to transmit, it also means that the server is essentially just generating JSON instead of rendering whole templates which also means a performance improvement for the client.

索引页面HTML大小为18KB。 如果我们仅使用JSON触发对相同URL的请求，则为4KB。 它不仅传输量少，而且还意味着服务器实质上只是生成JSON而不是呈现整个模板，这也意味着客户端的性能提高。

The platform is a work of beauty in general and I am amazed how little I have heard on the interwebs about it. So to give you an idea why it’s an incredible technical achievement on so many levels, here the breakdown.

该平台总体上是一件精美的作品，令我惊讶的是，我在网络上很少听到有关它的消息。 因此，请给您一个概念，为什么它在这么多的层面上都是一项令人难以置信的技术成就，以下是细目分类。

To understand what Battlelog is here a brief overview of what it does. These are not necessarily the features that are immediately obvious to the user but are very obvious for the interested developer that wants to peak under the hood:

为了了解Battlelog在这里的功能，请对其进行简要概述。 这些不一定是对用户立即显而易见的功能，但对于想要精打细算的感兴趣的开发人员来说，这些功能就非常明显：

In order to understand why Battlelog is interesting engineering we have to reconstruct what it appears to be doing. Again, I am not claiming knowledge of their server technology, I basically just observed what I saw and concluded a few things from it.

为了理解Battlelog为什么是有趣的工程，我们必须重建它似乎正在做的事情。 再说一次，我并不是在声称他们的服务器技术，我只是观察我所看到的，并从中得出一些结论。

When you access a page you get some nicely rendered HTML back. One of the things that is also transmitted to you is a large JavaScript document that contains their client side framework as well as the rendering instructions for all pages compiled to JavaScript code. The framework then hooks into your browser’s navigation code an intercepts all page loads. Instead of letting the browser replace the page with something new on load it instead does the HTTP request via Ajax and adds an additional header to the HTTP request: X-Ajax-Navigation. If the server side sees that header it will instead of rendering to HTML deliver the data that is normally passed to the template as JSON.

当您访问页面时，您会得到一些渲染良好HTML。 传输给您的内容之一是一个大型JavaScript文档，其中包含其客户端框架以及所有编译为JavaScript代码的页面的呈现说明。 然后，框架将挂钩到浏览器的导航代码中，并拦截所有页面加载。 它不是让浏览器在加载时用新的东西替换页面，而是通过Ajax发出HTTP请求，并向HTTP请求添加一个附加标头： X-Ajax-Navigation 。 如果服务器端看到该标头，它将代替渲染为HTML传递通常以JSON形式传递到模板的数据。

The data you get back is everything the page needs to render, including the name of the template. When that data arrives on the client the browser replaces the current page content with the data that was rendered on the client side from the received JSON. Not only that, it also makes sure to use the HTML5 history API to change the browser URL.

您获取的数据就是页面需要呈现的所有内容，包括模板的名称。 当该数据到达客户端时，浏览器将使用从接收到的JSON在客户端呈现的数据替换当前页面内容。 不仅如此，它还确保使用HTML5历史记录API更改浏览器URL。

The user does not notice that anything interesting is going on unless he’s tech savvy enough to open the firebug network panel and watch the system operate. In fact the whole thing is so incredible smooth that you would not notice anything interesting besides the fact that the page loads fast. I mean seriously fast. Clicking on a link in Battlelog is such a snappy operation it’s haunting for the trained web developer eye. Very few systems respond this quickly. This is especially noticeable on pages that do not involve a lot of different data such as the news section of the website or the forums.

用户不会注意到有什么有趣的事情发生，除非他精通技术以打开Firebug网络面板并观察系统运行。 实际上，整个过程是如此的令人难以置信的流畅，以至于您不会注意到页面快速加载这一事实。 我的意思是认真快速。 单击Battlelog中的链接是一个如此快速的操作，这对于训练有素的Web开发人员来说是一个困扰。 很少有系统对此做出快速响应。 这在不涉及很多不同数据的页面上（例如网站的新闻部分或论坛）尤其明显。

If you look at the website it also has a bar on the bottom of the screen that shows notifications, your friendlist, open chat windows and a few other things. This bar can have state. You can toggle windows open and closed, you can scroll in the chat window, enter new next and the bar will stay open and unchanged if you navigate to a different page. True, this is nothing special these days, facebook does it too. However from the design that Battlelog follows this comes natural. When the page contents are hooked in the DOM element for that bar on the bottom is preserved and not touched.

如果您查看该网站，则它在屏幕底部还有一个栏，用于显示通知，您的好友列表，打开的聊天窗口以及其他一些内容。 这个酒吧可以有状态。 您可以切换窗口的打开和关闭状态，也可以在聊天窗口中滚动，输入下一个新内容，并且如果导航到其他页面，则该栏将保持打开状态不变。 没错，这些天这没什么特别的，facebook也这样做。 但是，根据Battlelog的设计，这很自然。 当页面内容被钩在DOM元素中时，底部的该条将被保留而不被触摸。

The other aspect of Battlelog is the real time component with web sockets. I have not looked too far into that but it appears that it’s based on an abstraction layer on top of web sockets, Flash or whatever is supported that was written by ESN for other projects in mind as well. The server code sends an information to the push hub which handles the socket connection for the clients. This way various systems can inform the client about updates, that does not even have to be Battlelog itself.

Battlelog的另一方面是带有Web套接字的实时组件。 我还没有深入探讨，但似乎它基于Web套接字，Flash或ESN为其他项目编写的支持的任何东西之上的抽象层。 服务器代码将信息发送到推送集线器，该集线器处理客户端的套接字连接。 这样，各种系统就可以通知客户端有关更新的信息，而这些更新甚至不必是Battlelog本身。

While it’s not necessarily the case with Battlelog, there are a bunch of really good reasons why you want to render stuff on the client side:

虽然Battlelog不一定是这种情况，但您有很多非常好的理由要在客户端渲染内容：

Even if you do not have a JavaScript heavy application, moving computations to the client side is a good thing. This obviously assumes that it does not break the navigation like some websites do. Battlelog does not do that. The principles on which Battlelog is built would also very well work in a more traditional application. However it requires a well structured architecture were the data you’re sending to the template engine is simple (and secure!) enough that you can put it in JSON and that the templates themselves are simple enough that compiling them to JavaScript is an option.

即使您没有JavaScript繁重的应用程序，将计算移至客户端也是一件好事。 显然，这是假定它不会像某些网站那样破坏导航。 Battlelog不会这样做。 建立Battlelog的原理也可以在更传统的应用程序中很好地工作。 但是，这需要结构良好的体系结构，因为要发送到模板引擎的数据足够简单（并且安全！），您可以将其放入JSON中，并且模板本身也足够简单，可以将其编译为JavaScript。

Jinja2 for instance could in theory execute on the client but practically not. Practically it’s exposing a little bit too much of Python to make sense to compile to JavaScript. But a template language much like Jinja2 could be written that would make this possible.

例如，Jinja2在理论上可以在客户端执行，但实际上不能执行。 实际上，它暴露了太多的Python，因此无法编译为JavaScript。 但是可以编写类似于Jinja2的模板语言，从而使这成为可能。

In fact I think you could build a microframework that would very well support this paradigm and still be agnostic to the JavaScript code you’re running on the client for the most part.

实际上，我认为您可以构建一个微框架，该微框架将很好地支持这种范例，并且仍然与您在客户端上运行的大部分JavaScript代码无关。

The real interesting thing about Battlelog however is a Windows PC specific component. If you are heading to Battlelog from a Windows PC and you own the PC version of Battlefield 3 you can launch into a game right from within the browser. How does this work? It works with the help of a browser plugin that exposes additional functionality to the in browser client. Namely it has a function to start the game and pass it information as well as a general purpose function to ping an IP address which is used for the server browser.

但是，关于Battlelog真正有趣的是Windows PC特定的组件。 如果您要从Windows PC转到Battlelog，并且拥有PC版本的《 Battlefield 3》，则可以直接在浏览器中启动游戏。 这是如何运作的？ 它在浏览器插件的帮助下工作，该插件向浏览器中的客户端公开了其他功能。 即，它具有启动游戏并传递信息的功能，以及通用功能来ping服务器浏览器使用的IP地址。

In fact if you are playing on PC this is how the game is launched, always. There is no in game menu, you join from within your browser. This is mind blowing thing. First of all it makes it easier for DICE to update the server infrastructure since it’s now mostly separated from the client and also makes for much quicker iterations.

实际上，如果您在PC上玩游戏，那么始终都是这样启动游戏。 游戏菜单中没有，您可以从浏览器中加入。 这是令人震惊的事情。 首先，它使DICE可以更轻松地更新服务器基础结构，因为它现在基本上与客户端分离，并且迭代速度也更快。

The communication for the most part works in one-way but in a cycle as it seems. If you log into Battlelog and head to the server browser you get a list of servers. How does that work? Here’s how:

交流在很大程度上似乎是单向的，但似乎是循环的。 如果您登录Battlelog并转到服务器浏览器，则会获得服务器列表。 这是如何运作的？ 这是如何做：

Now here was me thinking. Would the plugin be necessary to accomplish all of the above things or could it be done in a different way? Native applications are here to stay, that’s a given. However more and more stuff of what a native application does can be moved into a browser for great success. So how does a web application speak to a native application?

现在我在想。 插件是完成上述所有工作所必需的，还是可以以其他方式完成？ 本机应用程序将保留下来，这已成定局。 但是，本机应用程序所做的越来越多的事情可以移动到浏览器中，从而获得巨大的成功。 那么，Web应用程序如何与本机应用程序对话？

The traditional way is by letting the application register a custom URL scheme and then letting the user click on that link which then launches the application. That’s unfortunately a one way communication only. But that might be everything that is needed.

传统方式是让应用程序注册自定义URL方案，然后让用户单击该链接，然后启动应用程序。 不幸的是，这仅是一种单向通信。 但这可能是所有需要的东西。

So here is how it could be done. Battlefield or any other application that wants to do the same but without the browser plugin could instead register a URL handler with a unique name. Let’s say battlefield3://. The operating system then knows about this URL scheme and can start a handling application. What can we do with this?

所以这是可能的方法。 战地或任何其他想要执行此操作但没有浏览器插件的应用程序都可以使用唯一名称注册URL处理程序。 假设Battlefield3：// 。 然后，操作系统知道此URL方案，并可以启动处理应用程序。 我们该怎么办？

The server component would have to uniquely identify a user for starters. Considering that each user has to log in that’s fine anyways. Then next to that user information one would have to remember if the game is running and how. What does that mean? Let’s start with the simple case: the game is not running. The Battlelog server looks at the current user and sees he or she does not have the game running. Consequently it will generate a unique token and generate a URL to the URL scheme (for instance battlefield3://start?token=.... It then generates a JavaScript prompt that informs the user that he has to launch the game by clicking on the link generated. This is the only chance in flow that is necessary. By clicking that link the user agrees that he wants to start that application.

服务器组件必须为初学者唯一地标识一个用户。 无论如何，考虑到每个用户都必须登录。 然后，在该用户信息旁边，必须记住游戏是否正在运行以及运行方式。 那是什么意思？ 让我们从一个简单的案例开始：游戏未运行。 Battlelog服务器查看当前用户，并看到他或她没有运行游戏。 因此，它将生成一个唯一的令牌并生成一个URL方案的URL（例如， Battlefield3：// start？token = ...） ，然后生成一个JavaScript提示，通知用户必须通过单击来启动游戏。生成的链接，这是唯一必要的机会，通过单击该链接，用户同意他要启动该应用程序。

But instead of launching the game it starts a daemon. That daemon takes the token and picks a random TCP port on the system and starts an HTTP server there. Once that server is running it notifies the central server that it’s running and on what port. Since the web browser has a push notification channel open it will get a notification now that the daemon is running and on which port.

但是，它不是启动游戏而是启动守护程序。 该守护程序获取令牌，并在系统上选择一个随机的TCP端口，并在那里启动HTTP服务器。 该服务器运行之后，它将通知中央服务器正在运行以及在哪个端口上运行。 由于Web浏览器打开了一个推送通知通道，因此它将在守护程序正在运行以及在哪个端口上运行时收到通知。

After that it can use HTTP and JSONP to communicate with the daemon. But how does the daemon know when to shut down? Basically that daemon will needs to be informed when to shut down. I would assume that 15 minutes without a ping from the browser would be a good indication that it should destruct itself. When shutting down it also tells Battlelog that it’s no longer running to clear out the port entry.

之后，它可以使用HTTP和JSONP与守护程序进行通信。 但是，守护程序如何知道何时关闭？ 基本上，将需要通知守护程序何时关闭。 我认为，如果15分钟内没有从浏览器中发出ping命令，这将很好地表明它应该破坏自己。 关闭时，它还会告诉Battlelog，它不再运行以清除端口条目。

Additionally to make this better it should not only record the port but also an identifier that uniquely identifies the machine the daemon is running on so that the user can alternate between different computers without ending up with weird behavior where the central server is informing the browser that the game is running when in fact it’s running on a different machine.

此外，为了使其更好，它不仅应记录端口，还应记录唯一标识守护程序运行的计算机的标识符，以便用户可以在不同的计算机之间进行切换，而不会因中央服务器通知浏览器该行为而产生怪异的行为。实际上，游戏在另一台计算机上运行时，该游戏仍在运行。

Since Battlefield 3 supports only one running game per user account it does not make sense to support more than one session. If that would be wanted it could obviously be done.

由于《战地风云3》每个用户帐户仅支持一个正在运行的游戏，因此支持多个会话是没有意义的。 如果需要的话，显然可以做到。

The downside here obviously is that it needs a websocket connection and a central server that acts as mediator between the different systems (daemon, client side app). In Battlefield 3’s case that would not be a concern (and already is not) since it’s an online game. The second problem here is that it needs one additional user interaction: the user has to click on the link to activate it. This currently is not necessary in Battlelog since it’s provided by a plugin.

显然，这里的缺点是它需要一个websocket连接和一个充当不同系统（守护程序，客户端应用程序）之间的中介的中央服务器。 在《战地风云3》的情况下，这是一个在线游戏，因此（现在已经不是）不必担心。 此处的第二个问题是，它需要额外的用户交互：用户必须单击链接将其激活。 由于它是由插件提供的，因此当前在Battlelog中是不必要的。

The whole concept of using a browser application as a frontend for a native application is an interesting thing indeed. Due to offline support becoming widespread that is also no longer a concern if the application can largely run in the client side. But that would break my above hypothetical example of interacting with a local application.

使用浏览器应用程序作为本机应用程序的前端的整个概念确实很有趣。 由于脱机支持变得越来越普遍，如果应用程序可以在客户端大量运行，也不再需要担心。 但这将破坏我上面与本地应用程序交互的假设示例。

Falling back to a browser plugin currently is the only way to make a consenting communication with a local application. I really wonder if there is not room for improvement by having an API in HTML5 that makes this possible which would also work for offline applications.

当前回退到浏览器插件是与本地应用程序进行同意通信的唯一方法。 我真的很想知道，通过在HTML5中使用API​​来使之成为可能，该API是否也可以用于脱机应用程序，是否没有改进的余地。

Basically what would be needed is a simple way for a two way communication with a local application. That application would have to register itself somewhere and then be able to respond to the client’s requests. It could totally work like a CGI script (eg: speak HTTP via stdin/stdout).

基本上，将需要一种与本地应用程序进行双向通信的简单方法。 该应用程序必须在某个地方注册自己，然后才能响应客户的请求。 它完全可以像CGI脚本一样工作（例如：通过stdin / stdout讲HTTP）。

I think there is a lot of potential for such applications in the future and Battlelog shows that it can be done already with a little help of a small plugin.

我认为这类应用程序在未来有很大的潜力，Battlelog显示，只需一个小插件就可以完成。

One last thing. Battlefield 3 sold a couple millions of copies. The PC users all have to update to recent version of their browsers since the website basically demands a modern browser. Even with all the fallbacks in place, it kinda forces people to update. For a certain audience websites like Battlelog can be the killer application of modern HTML5 features. Keep this in mind. In case you have a similar audience that’s something to take advantage of.

最后一件事。 《战地风云3》售出了数百万本。 由于该网站基本上要求使用现代浏览器，因此PC用户都必须更新其浏览器的最新版本。 即使有所有的后备措施，它仍然迫使人们进行更新。 对于某些受众来说，像Battlelog这样的网站可以成为现代HTML5功能的杀手级应用。 请记住这一点。 如果您有类似的受众群体，可以利用这一优势。

翻译自: https://www.pybloggers.com/2011/11/battlelog-modern-web-applications-are-here/